The response in my comment to this issues still applies - #167 (comment)

Health checks don't really provide much use other than an a queryable label on the running container.

It'd be great to understand what real-world use-case this particular solution solves to know on whether to proceed or not.

As an aside - i'm not sure this is a great approach to health check, all it does is validate that the broker has connected to zookeeper and been assigned a znode - it has no real indication of whether Kafka is healthy or not, the only half decent way of doing so is via a successful query to the brokers. Even with that said, if your brokers are in a distinct network from your clients and communication is via an external port a health check from inside the broker network becomes misleading, i.e. it could appear healthy but be completely unusable.

In my installation which may be slightly different but probably not so much.. the
shell commands ( ie : zookeeper-shell.sh ) use same env variables as kafka..
with the provided script there could be problems ie: if the pod is limited in memory to something less than 200% of the -Xmx or if the kafka is exporting JMX maybe would be usefull to reset/reimport from another name those variables

KAFKA_HEAP_OPTS="-Xms200M -Xmx500M"
## avoid conflicts on jmx ports with kafka 
KAFKA_JMX_OPTS=""
JMX_PORT=""